Русский
Русский
English
Статистика
Реклама

Управление персоналом

Пора что-то менять! Как определить ту самую токсичность в команде комментарии инженера

08.04.2021 18:23:51 | Автор: admin

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

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






Герои наших статей рассказывают, что корпоративная культура заграничных компаний, например, Uber, Booking иSpotify, разительно отличаются отроссийских: влияние токсичной команды насамочувствие ипроизводительность унас, кажется, пока недооценивают.


Новлияние это есть: Гарвардская бизнес-школа провела исследование навыборке из60,000сотрудников. Оказалось, что:


  • токсичное окружение статистически значимо влияет начеловека,
  • 38% людей намеренно работали хуже, чтобы избежать критики,
  • 12% из-за грубого обращения увольнялись.


Рассказывает Елена, QAAuto


Язадумывалась, что стоит менять работу, еще после испытательного срока. Что меня возмутило: компания невыполнила, что обещала насобеседовании. Говорили, что оформят ДМС апофакту выяснилось, смоим уровнем зарплаты ДМС вообще непредусмотрен. Неточтобы ямного болела, новедь всё, что мне говорили при приёме, оказалось неправдой.


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


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



По-моему, пора думать обувольнении иискать новую работу:


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





7признаков токсичного коллектива


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


  1. Нет дружеской атмосферы
    Банально, ноактуально: радыли люди работать вэтом месте? Атмосферу будет проще заметить новичку сотрудники привыкают кобстановке иперестают обращать внимание: рыбы невидят, какой мутной стала вода ваквариуме. Если, заглянув вофис, чувствуется холод, нет минимального общения, улыбок, обмена шутками похоже, что-то идёт нетак. люди неочень рады работать вэтом месте.
  2. Одержимость титулами, должностными инструкциями ииерархией
    При встрече снезнакомым человеком онвпервую очередь рассказывает про свой титул. Втоксичной среде власть для людей важнее миссии, которую они выполняют, ауспех измеряется статусом ибонусами, иужточно неуровнем доверия вкоманде.
  3. Правила везде, илюди боятся ихнарушать
    Правила важнее, чем мнение коллег: даже если оно основано намноголетнем опыте или погружении вконтекст. Формальность рулит, илюди боятся попасть внеприятности из-за нарушения правил. Поэтому никто невысовывается.
  4. Менеджмент против сотрудников
    Ещё чуть-чуть, истенка настенку: руководство исотрудники чётко разделены надве группы иредко взаимодействуют между собой. Аесли взаимодействуют, тообщаются водностороннем порядке: диалога нет.
  5. Фокус наслабых местах инедостатках
    О нарушениях, промахах ипровалах говорят очень много, аопобедах, достижениях мало. Победы непризнают, фидбэка мало.
  6. Нет диалога
    Невыполнимые цели, предлагают нелепые планы или откровенно глупые идеи непринято обсуждать, они воспринимаются как данность исотрудники пассивно наних соглашаются. Апозже жалуются вузком кругу наихглупость.
  7. Свободы действий при выполнении работы нет
    Процедура прописана для всех иочень чётко. Если людей вообще зачто-то хвалят, тозасоблюдение инструкций, анезановые идеи. Предложить изменения значит стать нашаг ближе кувольнению.

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


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


  • 80% людей опасались токсичности состороны коллег итратили рабочее время напереживания,
  • у66% заявили, что ихпроизводительность снизилась.

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


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


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


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


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


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


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


Думаете менять работу? Вботе @g_jobbot можно выложить своё резюме ипощупать рынок: проверить, какую зарплату может получать специалист свашим опытом. Это бесплатно: бот подберёт вакансии ипришлёт вТелеграм.
Подробнее..

Яблочный пирог или механизмы управления айфонами топ-менеджмента

06.04.2021 12:11:10 | Автор: admin

В управлении яблочными устройствами есть своя начинка специфика. Например, невозможно разработать приложение, которое управляло бы устройством. Функции управления доступны только самой iOS. Нельзя запретить пользователю отключаться от управления. После supervise нельзя восстановить данные из резервной копии. И так далее.

Под катом расскажем, как устроено управление iOS и каких корпоративных сервисов Apple не хватает в России.

Как устроено управление iOS?

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

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

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

Еще одна особенность iOS устройств это предлагаемые Apple механизмы управления IOS-устройствами:

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

  2. При установке профиля устройство регистрируется на сервере управления. При этом устройство сообщает серверу токен, по которому сервер может обратиться к устройству через APNS (Apple Push Notification Service).

  3. Когда серверу управления нужно доставить на устройство команду, он уведомляет об этом устройство с помощью APNS.

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

Сервер управления должен реализовать протокол управления Apple и отправлять уведомления о командах управления через APNS. Без уведомлений и APNS эта схема не работает. iOS устройство за командами само не придёт. Не барское это дело. Компании, как правило, не в восторге от необходимости предоставлять корпоративным серверам доступ к внешним интернет-ресурсам. Но в случае с управлением iOS устройствами альтернативы нет. При этом нужно открыть HTTPS и DNS порты всей подсети 17.0.0.0/8.

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

С помощью нашего клиентского приложения пользователь сможет зарегистрироваться в SafePhone и установить корпоративные приложения с сервера своей компании без App Store.
Например, клиент самописного ЭДО или персонализированная BI отчётность для руководителей.

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

Ещё клиент управления можно использовать для сбора информации о местоположении устройств. В SafePhone можно настроить график рабочего времени для отдельных подразделений и сотрудников. Опрос координат устройств будет вестись строго по этому графику.

Какие есть ограничения?

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

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

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

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

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

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

Чего не хватает в России?

Ключевой корпоративный сервис Apple Business Manager до сих пор недоступен в России. Надеемся, что следом за предустановленными российскими приложениями на iOS устройствах придёт и его черед.

С помощью Apple Business Manager можно управлять устройствами буквально с первого включения. Если компания и её устройства зарегистрированы в Business Manager, то настройки подключения устройств к корпоративному серверу управления сообщаются устройствам сразу при их активации. Эти устройства активируются сразу в supervised режиме и можно сделать так, что пользователь не сможет удалить настройки управления, т.е. устройства всегда будут находиться под управлением.

Второй важной функцией Apple Business является возможность покупки приложений для бизнеса. Сейчас российские компании не могут централизованно купить приложения в App Store.
Если пользователям для работы нужны платные приложения, обычно их покупают сами пользователи, а потом транжира-работодатель возвращает денежку с грустью в глазах.
С появлением Apple Business Manager российские компании смогут цивилизованно покупать софт для iOS, а потом с помощью систем управления распространять на корпоративные устройства купленные лицензии.

Часть российских компаний уже пользуются Apple Business Manager, но для этого они используют свои зарубежные представительства. Зарубежное представительство может зарегистрироваться в Apple Business Manager и добавить в него все корпоративные iOS устройства, включая российские. Создавать европейский филиал ради доступа к Business Manager, наверное, перебор.
Но если он уже создан, подключайте свои устройства через него.

Остались вопросы?

Если у вас остались вопросы по использованию iOS устройств в вашей компании, напишите нам на sales@niisokb.ru или оставьте комментарий к статье.

Мы будем вам признательны и обязательно ответим.

Подробнее..

Вы часть руководства? Отключите прием вызовов в телеграм! Баг-хантер? Уважайте других людей

13.04.2021 22:15:19 | Автор: admin

Всем привет. Сегодня речь пойдет не совсем о разработке. Я даже не знаю с чего начать. Это просто крик души.

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

Хто я?

Я - технический директор зарубежной компании. Прошел весь путь с момента идеи продукта и до текущего момента. По сути, мы - стартап, но вышли на самоокупаемость. Я часто отвечаю в поддержке для ускорения процесса если, конечно же, у меня есть свободное время. Итак, история началась 3 месяца назад. Наша команда в основном работает удаленно, но желающие могут посещать офис в Москве. Так вот, в конце января наш офис (а за одно и столицу) решил посетить один из сотрудников. Было принято решение встретить его с аэропорта. Должен сказать, я не отвечаю на телефонные звонки когда за рулем. И вот я еду в аэропорт, как мне начинает звонить раннее неизвестный мне человек в телеге. Я конечно же сбрасываю, но так просто я не отделался. Звонки начали повторяться постоянно. Сбросил - через 5 секунд тебе уже снова звонят. Ну что-ж. Выход очевиден: беззвучный режим и глаза на дорогу.

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

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

while (true) {  const rand = randomFloat();  if (rand > 0.9) {    writeMessage("Hi");    continue;  }    callTelegramm();}

После митапа я пишу "What happened?" ииии... Дальше ничего. Сообщение не прочитано, человек так сильно пытался до меня дозвониться и пропал. Через 3 дня он объявляется и сообщает что нашел аж 10(!) багов. Я думаю "как же так, 10 багов, я о них ничего не знаю". Логично что я сразу же занялся его вопросом и решил лично проверить все.

-_- ([%$#%^&$#] заголовок украден хакерами анонимусами)

После проверки "багов" оказалось что часть из них - возможность вытащить "личные данные пользователей". Звучит страшно, но на деле там оказалось что можно получить nickname пользователя, чей ник ты и так должен знать и (внимание) ID пользователя. Wow. Чтобы было немного понятнее: вы можете найти в телеграм пользователя по его нику. Чтобы его найти - вы и так должны знать ник. Это точно личные данные пользователей уязвимые для атаки? Вот такой же "баг" у нас нашли.

Другой "баг" - возможность доступа к открытым разделам приложения без оплаты. Мы сняли требование оплаты для того чтобы пользователь мог зайти в настройки и изменить емаил или пароль. Или же сменить тарифный план на бесплатный. Так вот как оказалось - это критическая уязвимость.

Еще могу рассказать как взломать абсолютно любой сервис. Как же? Все просто: открываете дев-тулзы на сайте и меняете текст в хтмл на свой личный. Для удобства представим что вы в сообществе вк добавляете модератора. Так вот вы находите в девтулзах слово "модератор" и пишете "владелец". А потом нажимаете кнопку, которая и выдает права. Проверять не стоит, ведь вы и так уверены что сообщество теперь принадлежит другому пользователю. Правда если все же проверить права - он окажется модератором, но это не важно. Звучит как ерунда? Я с вами согласен.

В конечном счете оказалось из 10 багов, за которые, кстати, тот самый нереальный охотник просил $2000, действительно багами считать можно только 2. И то они заключались в том, что мы не ограничиваем максимальное количество вводимых символов в инпут пароля при логине и регистрации. Казалось бы: можно попробовать забить сервер. Но при превышении максимального веса запроса - сервер сам отбросит его, да и к тому же у нас передается очень много данных между клиентом и сервером. Бывает возвращается ответ с 10к+ строк текста.

Пора поговорить о bug bounty

Решение было принято. За это платить $2000 не будем, оно того не стоит. Было предложено $400 за эти 2 момента. Но эта сумма не устроила охотника за багами. Он снисходительно снизил цену до $1500. 1500? Что? За максимальное ограничение символов? Его аргументом стало то, что это можно использовать для DDOS-атаки. Но DDOS-атака не проводится на поля для ввода. Она не так подбирается. Ищется место, в котором сервер медленнее всего обрабатывает запрос - очевидно там тяжелая работа с базой или какая-то дополнительная обработка, а может и в оперативу выгружает большое количество данных. И именно в этом место начинается атака чтобы положить сервер. В результате я предложил решение: проведешь успешную атаку с этим "багом" и мы поговорим об оплате за него.

Тут баг-хантер решил что пора понижать планку еще: до $1000. На самом деле $400 за эти "баги" и так сильно завышенная цена. После моего отказа - начались звонки - я отписал что в данный момент работаю и не могу ответить, но звонки продолжились. На следующий день все повторилось - я перенаправил его на других сотрудников, но с ними сей человек разговаривать не стал и продолжил долбиться ко мне в личку. В конце рабочего дня он отписал, что согласен на $600, после чего мы с ним еще раз поговорили и сошлись на 500, но без дальнейшего продолжения сотрудничества. После чего я связался с CEO компании и оказалось, что за день до этого ему уже перевели $500 (в тот момент, когда его это не устраивало). Я снова списался с охотником на баги и оказалось что он хочет еще $500. То есть в общей сложности $1000. И снова начались звонки... Я запретил ему в настройках звонить мне - он зарегал второй аккаунт, затем третий. После - начал звонить и писать в чат поддержки с требованием перевести ему еще со словами "иначе с вами никто не будет работать". Дальше - больше. Дело пошло к угрозам, жалобным и злобным эмоджи.

Потом пошел флуд в личку. И в конечном счете я не выдержал и отправил его в бан.

Может быть у кого-то были подобные проблемы? Как вы их решаете? Формально у нас не было компании на hackerOne. Этот человек сам нашел нас и сам же скинул баги и запросил цену. Мы готовы платить, но всему есть предел. Буду рад обсудить это в комментариях.

Мораль сей басни такова

  1. Не названивайте в телеграм постоянно. Если человек сбросил - он занят и обязательно ответит позже

  2. Не ломите цену. Ну ей богу. Ограничение по количеству символов в инпуте не стоит 2000 у.е. Оно и 500 не стоит если честно. Такими темпами можно будет оценивать отсутствие валидации полей на клиенте в тысячу долларов. А главным аргументом станет "Ну и что, что запрос не выполняется. Он же на сервер улетает. Запрос лишний - можно дудосить"

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

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

Подробнее..

Цифровая академия своими руками

13.04.2021 12:15:42 | Автор: admin


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

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

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

Сама концепция непрерывного образования появилась в работе Эдуарда Линдемана Значение образования для взрослых, опубликованной в США в 1926 году. Спустя 100 лет эти идеи актуальны как никогда.

Учиться, учиться и еще раз учиться!


Сегодня Группа М.Видео-Эльдорадо проходит через цифровую трансформацию. Внутри компании меняются подходы к управлению бизнесом и взаимодействию друг с другом.

Продуктовый подход перекочевал с офисных флипчартов в реальную жизнь. Компания внедряет концепцию One Retail, стирающую границы онлайн и офлайн розницы для сотрудников и клиентов компании.

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

Во многом, благодаря этому на базе Группы М.Видео-Эльдорадо была открыта Цифровая академия, корпоративная образовательная площадка для развития цифровых навыков и знаний у сотрудников и внешних кандидатов.



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

Периметр Цифровой академии включает в себя: цифровые компетенции, цифровую обучающую платформу, экосистему партнеров и контент.

Стоит сказать, что идея обучать сотрудников внутри компании далеко не новая. В М.Видео-Эльдорадо благополучно существует М.Академия.

Другое дело, что М.Академия не может сегодня закрыть все стоящие перед бизнесом актуальные вопросы, в том числе касающиеся цифровизации. Поэтому, в перспективе Цифровая академия должна вобрать в себя все существующие образовательные проекты.

Цели, которые решает Цифровая академия:

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

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

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

Речь идет не про абстрактные теоретические знания, а о сугубо практических вещах: программирование на Python, UX-дизайн, product-management, закрывающих узкие темы.

А учителя, кто?


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

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

Подходы к развитию цифровых компетенций


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

Именно поэтому, мы сформировали базовые принципы к развитию цифровых компетенций у сотрудников компании.

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

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

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

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

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

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

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

Модель цифровых компетенций


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

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

Ниже практический пример того, как за 5 месяцев с нуля внутри компании можно подготовить Middle product manager (простите за невысокое качество иллюстрации).



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

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

Как результат, через 5 месяцев, сотрудник может не только эффективно руководить магазином, но и успешно управлять продуктовыми командами внутри бизнеса. Причем, на middle-уровне.
Не менее интересен процесс развития цифровых компетенций. Это абсолютно приземленный и измеримый процесс, имеющий целью сформировать digital-навыки у членов нашей команды.

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

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



Модули Цифровой академии


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

Сегодня внутри Цифровой академии существуют следующие образовательные модули:

  • Основы трансформации и понимания бизнеса;
  • Продуктовая школа;
  • Школа Agile-мастеров;
  • Школа данных и аналитики;
  • Школа программирования и машинного обучения.

Ряд модулей уже запущены (Основы трансформации и понимания бизнеса, Продуктовая школа, Школа Agile-мастеров). Остальные запустятся до конца весны.

Обычно мы ищем на рынке признанных экспертов в выбранном нами направлении, формируем партнерство и адаптируем методический материал под наши прикладные задачи.

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

Так уж получается, что взять опыт трансформации сопоставимых с Группой М.Видео-Эльдорадо непродуктовых компаний в России нам практически не у кого. Поэтому нам интересно изучать не только российский, но и западный опыт.

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

Форматы обучения


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



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

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

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

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

Product school


Многие эксперты отмечают дефицит продуктологов на рынке. Спрос на людей способных внутри бизнеса эффективно координировать клиентские запросы и технологическое развитие внутренних IT-продуктов, крайне высок.

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

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

Предполагается, что 30-40% продуктологов мы привлечем извне, а 60-70% будут выращены внутри компании. Это необходимо для сохранения баланса между существующим опытом и внешней экспертизой, причем не только в области ритейла.

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

Про деньги и отбор


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

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

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

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

Сегодня Группа М.Видео-Эльдорадо работает в гибридной модели занятости персонала. Это предполагает микс из удаленного и традиционных форматов работы.

Взгляд за горизонт


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

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

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

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

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

imageМихаил Карпов, генеральный директор и Со-основатель ProductStar:
Миссия команды ProductStar через передачу экспертизы способствовать тому, чтобы вокруг каждого из нас появлялись высококачественные и удобные продукты. В данном совместном проекте с компанией М.Видео-Эльдорадо мы видим отличную синергию: команда экспертов ProductStar делится методами по развитию продуктового подхода в российских и международных компаниях, а коллеги из М.Видео-Эльдорадо, как один из флагманов индустрии, обогащают его своим глубоким отраслевым опытом e-Commerce!.
Подробнее..

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

09.04.2021 14:13:02 | Автор: admin
В последнее время много копий сломано вокруг технических собеседований. Очевидно, что инвертирование двоичного дерева на доске практически никак не связано с практическими навыками реального программиста. Примитивный Fizzbuzz по-прежнему остаётся самым эффективным тестом. Как следствие, выросло внимание к опенсорсным проектам, но оказалось, что это тоже не очень хороший показатель, потому что у большинства профессионалов нет на них времени.

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

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

Factorio?


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

Начинаете с нуля. Добываете вручную железную руду и камень, строите плавильную печь, чтобы плавить руду в железные пластины, из которых можно скрафтить автоматический твёрдотопливный бур. Можно самостоятельно забирать железную руду из бура и закладывать её в плавильню, но более эффективно использовать автоматический конвейер. Потом можно использовать полученное железо, чтобы сделать другой бур, который автоматизирует добычу угля. Затем строится конвейер для забора угля и конвейер для его передачи в бур. Эта крошечная фабрика производит железные пластины, из которых можно сделать третий бур и начать добычу медной руды, которая позволяет крафтить медные плиты, а из них можно сделать медный провод, необходимый для работы погружного насоса. В сочетании с паровым котлом и паровым двигателем это даёт нам первую электроэнергию. Её можно использовать для исследовательского центра и изобретения новых технологий, таких как сборочный автомат. Как только разблокируете сборочные автоматы, можете использовать сделанный вручную провод для создания сборочной машины, которая будет автоматически изготавливать эти провода.

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

Выбор направления


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

Конкретные ожидания можно сформулировать так:

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

Командная работа


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

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

Отладка


Одним из главных навыков для программиста является отладка. Это, пожалуй, самая очевидная параллель между Factorio и реальной разработкой ПО. Что-то может сломаться очень далеко от фактического источника проблемы. Способность быстро выяснить реальную проблему это критический навык, и процесс мышления почти идентичен отслеживанию причины сбоя в реальной программе. Если перестал работать сборочный автомат, сначала нужно проверить выходящие потоки. Потом проверить, какого ингредиента не хватает на входе. Затем проследить ингредиент по фабрике, чтобы узнать, где он производится. И повторять процесс снова и снова, до тошноты.

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

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

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

Код-ревью


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

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

Стиль написания кода и фреймворки


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

Конструкция магистрального ленточного конвейера включает 4-8 конвейеров, разделённых на две секции (для подземных конвейеров). Он помещается в центре фабрики, и всё производство происходит перпендикулярно ленте. Эта конструкция опирается на несколько правил, нарушение которых может привести к полному хаосу. Во-первых, всегда следует использовать разделитель на выходе с конвейера. Никогда нельзя перенаправлять всю ленту: пустое пространство для другой ленты означает, что вы теряете целый конвейер ресурсов, даже после апгрейда. Во-вторых, все заводы должны масштабироваться перпендикулярно основному конвейеру. Невозможность быстрого масштабирования приведёт либо к огромной потере пространства, либо к невозможности масштабирования производственной линии, потому что она окружена другими производственными линиями.


Логистическая сеть

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

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


Неоптимальный дизайн завода на дронах, источник

Многопоточность


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

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

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

Масштабирование


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

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

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

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

Микросервисы и модули


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

Мегабазу на основе поездов иногда называют дизайном городских кварталов (city-block), где поезда вокруг кварталов завода контролируют все входы и выходы. Таким образом, каждый отдельный квартал изолирован от всех остальных, поскольку все входные данные чисты в том смысле, что они поступают из железнодорожной сети. Это почти идентично архитектуре микросервисов (по HTTP) или межпроцессному взаимодействию (IPC), с аналогичными потенциальными проблемами из-за задержек I/O, поскольку результаты не могут поступать постоянно, они должны передаваться в пакетах или поездах по железнодорожной сети.

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

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

Распределённые системы


Space Exploration полностью переделанная версия Factorio для колонизации космоса. Здесь планеты становятся ограниченными ресурсами, требуя от игроков колонизировать другие миры и использовать ракеты для передачи ресурсов между планетами. Из-за огромной задержки с доставкой материалов между планетами, координация этих баз приводит к возникновению проблем, сходных с глобально распределённой системой баз данных. Даже в логической сети приходится бороться с задержкой, потому что автоматическая система теряет из виду элементы, которые запущены, но ещё не достигли целевой планеты. Если это не учитывать, возникают дубликаты запросов для всех нужных элементов. С точно такой же проблемой сталкиваются распределённые системы при попытке обеспечить согласованность между узлами.

Вывод


В целом софтверная индустрия не имеет ни малейшего представления, как находить и нанимать лучших разработчиков. Наверное, совместная игра в Factorio стала лучшим техническим собеседованием, которые мы когда-либо проводили. И это нас сильно смущает. Такое собеседование дико непрактично, занимает более 20 часов в мультиплеере с первого раза или 8 часов для команды опытных игроков. Что из этого можно извлечь? Не знаю. Мы, конечно, не можем перейти на Factorio в качестве метода собеседований с таким же успехом можно просто дать кандидату домашнее задание.

Но это уже лучше, чем собеседование на доске.
Подробнее..

Перевод Daily Standup пустая трата времени

07.04.2021 16:22:59 | Автор: admin

Обычный рабочий день. Тот же самый daily standup, который вы посещаете годами. Вы приходите в одно и тоже время. Немного общаетесь со своими товарищами по команде. Потом руководитель интересуется, как вчера прошла чья-то работа.

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

Этот формат вроде как работает.

Я имею в виду, что для одних команд это нормально, а для других отстой. Почему люди жалуются на daily standup на командных встречах? Почему одним это нравится, а другим нет? Поразмыслив над этим в течение нескольких лет, я пришел к следующему выводу:

Меня не волнует, что ты сделал вчера.

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

Меня волнует, насколько команда продвинулась к своим целям.

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

Имеет ли значение daily standup?

Что такое daily standup?

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

  • Что я сделал вчера, что принесло пользу команде?

  • Что я планирую сделать сегодня, чтобы внести свой вклад в команду?

  • Какие препятствия мешают мне или команде достичь поставленных целей?

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

В оставшейся части этого поста я буду называть этот формат традиционным.

Проблемы формата Daily Standup

Проблемы с традиционным daily standup это отсутствие фокуса и обсуждение не по теме. Когда я прихожу на эту встречу, у меня в голове возникают следующие мысли:

  • Я начинаю думать о своем вкладе, чтобы доказать свою полезность;

  • Люди отключаются, когда товарищ по команде начинает говорить о том, что их напрямую не касается;

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

  • Мы выходим за временные рамки и заканчиваем, когда другая команда начинает мельтешить у входа в комнату в ожидании своего daily standup.

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

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

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

  • Больше людей приносят больше нововведений.

  • Больше нововведений больше информации, на которую другим людям будет наплевать.

  • Команда может работать сразу над несколькими проектами.

  • Если у команды есть клиенты, то регулярно будут озвучиваться особые виды деятельности.

Проще говоря, традиционный формат daily standup не масштабируется.

Масштабируемый формат daily standup: Walk the Board

Я добился большого успеха в использовании формата Walk the Board для больших ежедневных выступлений. Этот формат по-прежнему отвечает на критические вопросы:

  • Что было сделано вчера?

  • Что запланировано на сегодня?

  • Что мешает команде добиться прогресса?

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

Этот формат работает следующим образом:

  • Создайте доску, на которой будет отображаться статус каждого элемента, над которым работает команда.

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

  • Обязательно спросите: Что нужно, чтобы переместить этот элемент на следующий этап прогресса?

  • Выделите проблемы, мешающие работе.

  • Перейдите к следующему столбцу слева и получите обновления для каждого тикета в этом столбце.

  • Продолжайте, пока не дойдете до самого левого столбца.

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

Теперь может показаться, что этот формат занимает много времени. Но это не так!

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

Что делать, если формат Walk the Board слишком долгий?

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

Если вам нужно обсудить слишком много вещей , стоит подумать, как ваша команда может взять на себя меньше элементов? Как исправить это тема для другого разговора. А пока я рекомендую прочитать книгу Agile Project Management with Kanban.

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

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

Значение играет не сам Daily standup, а время после него.

После многих лет посещения daily standup я начал замечать кое-что особенное. Они зачастую были однотипны, но после встречи

Все в команде общаются.

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

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

Это заставило меня понять, что настоящая ценность daily standup не сама встреча, а время, которое наступает после неё.

Учитывая это, давайте перестанем пытаться оптимизировать саму встречу. Вместо этого используйте её как катализатор, чтобы увести ваших товарищей по команде от их рабочих мест. Используйте daily standup, чтобы начать разговор, но доверяйте команде, чтобы она сама закончила его.

Заключение

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

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

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

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

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

Подробнее..

Перевод Простая жизнь людей

07.04.2021 20:14:16 | Автор: admin

В связи со скорым стартом онлайн-курса "Team Lead" приглашаем всех желающих записаться на открытый демо-урок Первые шаги тимлида на новом месте. На вебинаре участники вместе с экспертом обсудят:
С чего начать работу новоиспеченному лиду?
На какие процессы стоит обращать внимание?
В каких местах кроются quick wins для быстрого роста?

А сейчас предлагаем к прочтению традиционный перевод интересного материала.

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

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

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

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

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

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

Всё должно быть сделано просто насколько возможно, но ничуть не проще. Это высказывание Эйнштейна неправильно цитируют, упуская из вида последнюю часть, но ничуть не проще, или как он сказал самом деле: адекватное представление базовой единицы опыта (the adequate representation of a single datum of experience). Я думаю, что Эйнштейн пытается сказать, что цель не простота, а понимание.

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

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

Хомский (Chomsky) и Герман (Herman), вероятно, наиболее известны тем, что описали, как подобные методы работают в пропаганде. Они утверждают, что, ограничивая параметры дискуссии, мы фактически вырабатываем одобрение общественности. Что, на мой взгляд, работает как для общества, так и для организаций.

Например, можно упростить сложный набор идей в крылатую фразу, с которой трудно не согласиться, например Сделаем Америку снова великой (Make America great again), Надежда (Hope), Перемены (Change), Мир (Peace) и т. д. Это заставляет нас ощущать глубину дискуссии где-то на уровне детского бассейна; когда на самом деле ее глубина подобна океану. Поддерживаете ли вы наши войска? это не тот же вопрос что Поддерживаете ли вы политику, связанную с войной, в которой они сражаются?. Хомский говорит, что вы должны НАЧАТЬ, сказав: Ну, я НЕ не поддерживаю войска, но к тому времени вы уже проиграли.

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

Простота идеальное средство радикализации монистической мысли.

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

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

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

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

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

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

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

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

Cynefin framework отправная точка для работы со сложностью

A Leader's Framework для принятия решений

Можете ли вы упростить сложность?

На Media ч. 1 - Согласие на производство (подкаст)


Узнать подробнее о курсе "Team Lead".

Смотреть вебинар Первые шаги тимлида на новом месте.

Подробнее..

Про outsource и product компании

10.04.2021 14:17:23 | Автор: admin

Всем привет.

Я team lead, сертифицированный коуч и начинающий психолог.

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

Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

В этой статье хочу поделиться своим видением текущей ситуации на рынке.

  • За время работы заметил следующие интересные феномены:

  • В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях в процессах

  • В продуктовых компаниях меньше менеджмента

  • В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)

Ни на одном проекте не встретил аналитику в outsource.

Здесь думаю следует пояснить, что такое outsource.

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

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

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

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

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

Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле пожаловаться друзьям. Однако в случае outsource компании возможность пожаловаться является услугой, оказываемой такому заказчику.

Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.

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

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

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

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

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

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

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

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

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

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

И здесь есть интересная ловушка.

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

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

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

Для упрощения воспользуемся метафорой семьи.

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

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

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

Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

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

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

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

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

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

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

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

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

Такой конфликт спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

От сюда и появляется первый феномен (из начала статьи).

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

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

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

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

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

Подробнее..

Основные проблемы в командах разработки и их решения

12.04.2021 20:16:10 | Автор: admin

Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся темой управления командой подготовили статью, автором которой является Сергей Колосков.

Также приглашаем всех желающих посмотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?
За 1,5 часа на примерах реальных продуктов вы узнаете:
- почему успех продакт-менеджера это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- узнаете, что может сделать продакт-менеджер для улучшения unit-экономики.


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

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

Проблема 1: Много идей и разговоров, работа движется медленно

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

Диагноз: в команде нет людей на две роли:

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

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

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

Проблема 2: Ступор при проблемах и затруднениях

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

Диагноз: не хватает ролей, приносящих новые идеи. За них отвечают две роли Генератор и Исследователь ресурсов, и они совсем разные:

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

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

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

Проблема 3: Бесконечные споры между конкурирующими идеями

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

Диагноз: в команде несколько конкурирующих Генераторов или Исследователей ресурсов, конкурирующих за реализацию своих идей. Два Генератора в команде такая же плохая идея, как и ни одного.

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть.

Проблема 4: Реализация сложных идей процесс, не результат

Бывает и так, что идеи есть, но они сложные. В этом случае команда либо не движется к результату, либо останавливается где-то на полпути. Это случается, когда есть мощный генератор, придумывающий новые сложные фреймворки и идеи, и которые сразу идут в реализацию. Но потом выясняется, например, что декларативное описание форм, которое он придумал, 100% проблем не решает, и даже 50% решает с трудом. Он его усложняет, но все кейсы и особые случаи все равно не натягиваются, и начинается ступор.

Диагноз: идеи от Генератора принимаются без рефлексии.

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

Проблема 5: Паралич принятия решений

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

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

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

Шейпер это более традиционный харизматичный руководитель, который активно и жестко ведет команду к принятым целям по выбранному им пути: Идем туда!

Лечение: внешнее руководство в точках принятия решений. Когда этот процесс налажен, неожиданностей почти не бывает.

Проблема 6: Слишком уверенный лидер

Диагноз: у руководителя-Шейпера нет уважаемого им оппонента Координатора для обсуждения решений. Это обратная сторона Шейпера без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий.

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

Проблема 7: Непродуктивная команда звезд

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

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

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

Лечение: Команде звезд нужен опытный руководитель-координатор, принимающий решения, потому что кто-то должен быть арбитром.

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

Проблема 8: Некому завершать работу

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

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

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

Лечение: чек-листы и административный контроль за реальным завершением задач не нужны, когда педант есть в команде.

Проблема 9: Нет сотрудничества

Симптомы: поиск виновных в проблемах и неудачах, отсутствие взаимопомощи, люди указывают на несовершенства других.

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

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении.

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

Формирование команды с учетом знаний о проблемах

Момент 1: Пригодность и приемлемость

При составлении команд имеют значение как профессиональные знания и навыки, так и приемлемость по командному профилю (роли):

  • Пригодные и приемлемые им работа скучна, это просто ступенька карьеры.

  • Приемлемые и непригодные развиваются, и им интересно работать в команде.

  • Неприемлемые, но пригодные проблемные. Работу делают, но в команде из-за них возникают трения.

  • Непригодных и неприемлемых надо уволить из команды в другой команде они могут подойти по профилю и проявить свои сильные стороны.

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

При формировании команды:

  • Нужны идеи, исполнители и организаторы.

  • Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.

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

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

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

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

  • Однородные команды слабы и часто выбирают себе подобных.

  • Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды.

Момент 2: Состав сбалансированной команды:

  • Руководитель Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;

  • Один сильный Генератор;

При этом хорошим будем следующее распределение умственных способностей:

  • умный Генератор;

  • еще один умный не-Генератор, который ему оппонирует;

  • умный Координатор;

  • остальные чуть ниже среднего уровня.

Момент 3: Размер команды

Оптимальный размер команды 5-7 человек:

  • Ни 5, ни 7 человек не проигрывают и не выигрывают;

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

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

  • В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.

Момент 4: Команды-победительницы

  • Смешанные сбалансированные команды, где представлены все роли.

  • Однородные команды из стабильных экстравертов. В IT это редкость, но все же такие встречаются. Эти команды хорошо работают за счет сотрудничества, так как им нравится трудиться вместе. Роли в таких командах могут быть не выделены, но сотрудничество помогает преодолеть проблемы. Правда, они так же весело могут пойти на дно.

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

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


Узнать подробнее о курсе "Product Manager IT-проектов"

Смотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?

Подробнее..

Перевод 13типовразработчиков,скемяработал

17.04.2021 10:20:32 | Автор: admin

Вы можете любить или ненавидеть их, но вы не можете игнорировать их.

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

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

1.Продавецдыма

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

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

2.Мультизадачныйразработчик

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

3.Специалистссертификатами

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

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

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

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

Конечно, сертификаты или степень в образовании это прекрасно, но только если это подтверждено реальным опытом, иначе вы становитесь разработчиком-теоретиком.

4.Неряшливыйразработчик

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

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

Увасможетбытьмногоключей,чтобыраспознатьнерях:

  • Упорядоченылиихзаметки?

  • Записываютлиони,чтобынезабыть?

  • Приведёнлиихрабочийстолвпорядок?

5.Разработчик-теоретик

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

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

6.Рядовойразработчик

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

7.Боязливыйразработчик

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

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

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

8.Универсальныйразработчик

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

9.Нарцисс

Обычно имеют огромное эго и плохие командные навыки.

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

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

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

10.Одержимыйвсемразработчик

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

11.Единорог

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

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

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

12.Быстрыйразработчик

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

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

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

13.Разработчик,которыйвсегдахочетпомочь

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

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

Заключение

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

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

Подробнее..

3 пути к возрождению организации

19.04.2021 00:19:54 | Автор: admin

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

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

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

Начнем со знакомством с философией трех путей:

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

  • Второй Путь - это движение по дороге улучшений за счет построения циклов обратной связи.

  • Третий Путь пропагандирует культуру постоянного эксперимента. Движение дорогой проб и ошибок позволяет организации расти и развиваться.

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

О них дальше и поговорим.

Визуализируйте всю работу

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

  • бизнес проекты - тип работы, которая создает ценность для конечного пользователя и/или конкурентное преимущество организации;

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

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

  • незапланированные работы - три предыдущих типа работ мы планируем, в то время как четвертый появляется против нашей воли и ставит под сомнение все наши планы. Зачастую они появляются после "срочных" изменений.

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

Выявляйте ограничения

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

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

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

Устраняйте ограничения

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

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

Устраняйте движение против потока

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

Наладьте обратную связь

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

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

Экспериментируйте

Развитие технологий и глобализация открыла новые возможности для бизнеса. Сегодня маленький стартап из Израиля или Беларуси, может конкурировать с гигантом из США или Европы за аудиторию. Пользователь становится более избирательным, а конкуренты не дремлют. Если вы будете довольствоваться тем, что есть, то очень быстро вас догонят и перегонят. Эксперименты - основа основ для развития. Как сказал Эдисон: "Каждая неудавшаяся попытка это еще один шаг вперед". Чем больше компания экспериментирует тем выше ее шансы найти нужный подход к аудитории и монетизировать его. Это и есть ключ к третьему пути.

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


Подробнее..

Задачки для CTO на собеседовании

06.04.2021 14:13:41 | Автор: admin

Вдохновившись постом "Собеседование в Яндекс: Театр абсурда" хочу поделиться своими весёлыми историями.

Я не то, чтобы редко собеседуюсь на работу - я этого обычно вообще не делаю. У меня и резюме-то нет, по большому счёту. Мой основной род деятельности - CTO и co-founder в IT-стартапах.

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

История первая

В далёком 2011 я стал со-основателем и CTO стартапа в области новых финансовых технологий. Стартап рос и органично развивался, однако затем, скажем так, потенциальные юридические расходы стали слишком высоки и учредители решили закрыть компанию. А мой давний друг Frank предложил купить все технические наработки стартапа и пригласил меня поработать CTO в его компании в Стокгольме. Я с радостью согласился, у них была небольшая команда и было огромное поле для деятельности в области улучшения процессов разработки.

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

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

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

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

В назначенный час я на связи, звоню, там на видео вежливый парень со славянским именем и фамилией. Говорю - привет, как дела, он отвечает - хорошо, но I prefer English for essential things. Тогда мне показалось, что наше интервью слушал кто-то ещё вне видимости камеры, но мне об этом не сказали.

Он сперва попросил рассказать о себе, мы очень хорошо поговорили десять минут - я рассказывал о своём опыте управления разработкой, он задавал уточняющие вопросы, очень тактично затем немного рассказал о технической части со своей стороны и прозвучала сакраментальная фраза Were going to do a bit of coding, it should be fairly easy for you.

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

Как там @kesnписал - Ну ок, решили проверить знание базовый вещей. Не окей! Я очень вежливо, но настойчиво отказался (в задачи CTO компании любого уровня сложности входит много всего интересного, но умение решать алгоритмические задачки - точно не ключевая компетенция).

Интервьюер оказался очень хорошим человеком, и ответил - окей!, тогда поговорим про ваш опыт как project manager и CTO. И мы провели оставшееся время в увлекательной беседе, которая, как мне показалось была ему интересна (судя по множеству вопросов по-сути, а не для галочки).

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

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

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

История вторая

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

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

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

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

Вместо послесловия

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

А вообще мне просто захотелось рассказать вам эти истории, надеюсь, вы посмеялись также, как и я :-)

Подробнее..

Перевод Рекрутмент-маркетинг в современных реалиях

06.04.2021 20:05:58 | Автор: admin

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

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

Ниже приведены мои советы по оценке вашей стратегии на 2021-ый год, которые нацелены помочь вам нести правильный посыл, делиться опытом и сделать вашу политику максимально эффективной.

Цели и стратегия привлечения соискателей

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

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

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

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

  • Какие реальные проблемы помогает решить ваша компания?

  • Какова цель кампании? Вы просто хотите нанять всех и каждого?

  • Вы все еще создаете свой кадровый резерв, который, вероятно, вообще не собираетесь использовать? Серьезно?

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

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

Фото и видео

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

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

Когда вы начинаете работать над своим квартальным планом публикаций, следует учитывать несколько моментов:

COVID

Делясь своими фотографиями и видео, помните, что есть такая небольшая проблема, как COVID-19, который все еще распространяется по всему миру.

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

Если ваша команда работает удаленно, ваши фото и видео должны это отражать.

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

Дайверсити и инклюзивность

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

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

Стоковые Фото

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

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


Узнать подробнее о курсе "IT-Recruiter".

Смотреть вебинар Как из человека сделать it-рекрутера.

Подробнее..

Перевод Как НЕ надо нанимать разработчика софта

07.04.2021 04:04:38 | Автор: admin
image

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

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

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

Не стремитесь к лучшему решению


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

Это можно понять в конце концов, у них есть только 45 минут, и они хотят обсудить с вами много вещей.

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

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

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

Не задавайте головоломок


Как проверить, есть ли в связанном списке цикл? Помещается ли одна N-мерная коробка в другую N-мерную коробку? Можете ли вы поменять местами две переменные без третьей? Как найти кратчайшее расстояние между двумя движущимися кораблями? Найти все перестановки из N элементов, выполнив только N-1 перестановок?

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

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

image

Как спаситись, до того как свеча пережгет веревку?

Будьте открыты для альтернатив


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

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

Никто не знает всего. Будьте открыты. Слушать. Размышляйте. Да, даже если вы интервьюируете кого-то.

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


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

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

Так что ошибки на самом деле хорошо, потому что вы узнаете, как этот человек их исправляет. Не судите об ошибках, оцените, как собеседник их обрабатывает:

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


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

Позвольте мне проверить!


Серьезно, а что такое написание программы на маркерной доске?

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

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

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

image

Изучайте глубже


Пять коротких интервью? Или два длинных?

С пятью вы получите пять независимых мнений, что лучше, чем два. Но насколько глубоко вы можете погрузиться за 45 минут? Практика показывает, что достаточно написать 20-30 строк кода и задать пару действительно простых вопросов (в чем сложность? Как тестировать?).

Следующий интервьюер просто повторяет тот же процесс, доходя до предыдущего. Что недолго. Совсем недолго.

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

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

А если хотите больше мнений? Посадите в комнату несколько интервьюеров, чтобы они потом спорили.

Изучите предысторию


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

Меня когда-нибудь спрашивали об этом? Нет.

Я получаю: Представьте, что у вас есть функция, которая принимает список пять раз подряд. Пять задач школьного уровня должны дать вам адекватное представление, о чем? Насколько внимательно я читал Кормена и др.? Честно говоря, о них тоже редко спрашивают.

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

Сделайте процесс плавным


Неправильное направление? Задержанные билеты? Анкета, требующая установки оригинального Adobe Reader специально? Дешевый ультрабук с незнакомой раскладкой клавиатуры и плохим веб-редактором без каких-либо ярлыков, который тормозит даже на локальной машине? Извините, я нахожусь в офисе самой способной IT-компании в мире, не так ли?

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

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

Да, я считаю, что любой может добиться большего.

image

В заключение


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

Хорошего найма!
Подробнее..

Как дать сотрудникам долю от результата в малом бизнесе и стоит ли им её брать

12.04.2021 08:19:59 | Автор: admin
Мы делили апельсин Много нас, а он одинМы делили апельсин Много нас, а он один

В статье Давать ли сотрудникам долю в бизнесе мы рассмотрели точки зрения сторон за и против, проблемы и риски возникающие при передаче доли в собственности. Там же было сказано про долю от урожая как мотивацию. Если оборудование дата-центра покупалось не за счёт сотрудников, то нелогично, что им может принадлежать часть этого оборудования. А вот доля от эксплуатации им может принадлежать.

Если посмотреть на опционы сотрудников акционерных обществ, то акции дают вообще сомнительные права. Никаких реальных прав собственника на имущество организации нет за исключением права продать свои акции. Нет даже права на дивиденды. Рассмотрим щедрость Тинькова к своим сотрудникам. Тинькофф имеет 199.3 миллиона акций. Олег 5.3 миллиона акций в течение 5 лет будет раздавать 300 сотрудников. У Олега какая-то любовь к цифре 3 на хвосте. 5.3 миллиона от 199.3 это всего 2.66% от компании. В относительных единицах я намного щедрее.

Зачем давать сотрудникам долю от урожая

Уже же есть KPI и сотрудник имеет оклад и премию. И это работает. Доля от урожая это следующий уровень мотивации после KPI.

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

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

  3. Для компании и сотрудника это ещё один вариант расчёта стоимости услуг сотрудника.

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

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

Интересы сторон

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

Сотрудник:

  • подчиняется Трудовому кодексу;

  • трудовому распорядку;

  • своему руководителю;

  • должностным инструкциям;

  • имеет учёт в часах.

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

Важно гарантией для партнёра является невозможность разорвать договор с ним. Поэтому все в основном и смотрят только на доли в компании. Право разорвать договор у заказчика есть в соответствии со статьёй 782 ГК РФ. Для решения этой проблемы была написана статья Заказчик не платит: как защититься или как забрать свой аванс у арендодателя?. То есть в договор прописвается изменение стоимости услуг исполнителя на 100% за последние три года. Такой же мультипликатор по прибыли используется при продаже некоторых видов бизнеса.

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

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

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

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

Сравнение опционов и доли от урожая

Все эти акции дурилка картонная, потому что цена акции слабо зависит от сотрудника, если только этот сотрудник не человек-бренд. Стоимостью акций можно манипулировать. Инсайдеры откупятся на низах, а продадут на максимумах. И не раз поимеют всех. В США за это посадят, а в России пока прецедентов не было.

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

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

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

Надо чётко понимать, что любой вариант это вариант баланса разных компонентов: дохода, рисков, ответственности, обязательств. Эти компоненты связаны. Либо это, либо то.

Фишка для азартных

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

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

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

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

Как мы делим деньги: фондирование

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

У нас есть формулы для фондирования. Формула для веб-студии и отдела поддержки сайтов и серверов, где основной вклад вносят мозги и руки сотрудников.

ФЗП=0.75*(доход-транзитный расход).

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

Для дата-центра работает вложенный капитал в оборудование и серверы, поэтому там формула немного другая.

ФЗП технического персонала дата-центра = 0.32*(доход-транзитный расход).

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

У ключевых сотрудников есть своя доля от пирога. Это не доля от прибыли. Это не собственность. Это скорее как процент от участия в артели.

Недостатки стандартного метода распределения прибыли

Эти недостатки для меня. Для кого-то они достоинство. Экономика не совсем наука как математика и физика. Экономика это помесь веры с математикой. Если бы экономика была наукой, то все экономисты были бы миллиардерами.

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

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

Поэтому я эту схему и не использовал. В моей схеме (можете называть её схемой Игоря Тарасова, если её никто не изобрёл ранее) конфликта нет. Но она не будет работать, если доход слабо превышает транзитные расходы.

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

Проблемы составления договора

Все договоры хорошо работают для джентльменов. Почти любой договор и любые правила можно развалить злыми намерениями. Недаром к правилам дорожного движения народ придумал правило трёх Д дай дорогу дураку. А в ГК РФ есть статья 10.

У нас нет точки опоры на все случаи жизни. Жизнь нельзя запрограммировать и подчинить чётким правилам как стрелки механических часов. Можно найти объективные критерии вроде uptime. Но прописать порядок передачи дел уже задача не столь тривиальная. Формально дела могут быть переданы, а по сути тонкие моменты не сообщат и без них часовой механизм остановится.

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

P. S.

Если вы за, то наши вакансии здесь.

Подробнее..

Быть тимлидом, ч2 Технологии

13.04.2021 12:15:42 | Автор: admin

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


Об уровне владения технологиями



Должен ли тимлид быть самым-крутым-нинзя-рокстар разработчиком? Вопрос дискуссионный. Зависит от компании: где-то тимлид сам проектирует архитектуру, принимает все ключевые решения по реализации функциональности, проводит code review, отвечает за релизы; а где-то эта роль подразумевает управление людьми, и в команде есть техлид, закрывающий основные технические вопросы.


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


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


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

Должен ли тимлид постоянно писать код?


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



Я отнёс к блоку технологий в обязанностях тимлида четыре области:


  • инженерная культура;
  • Agile-процессы;
  • SLA;
  • постоянное улучшение качества.

Что я понимаю под инженерной культурой?


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


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


  • архитектурные стандарты;
  • типовые решения;
  • правила оформления кода (stylе guides);
  • стандарты code-review;
  • автомацизация рутинных операций;
  • практики сообщества;
  • работа с техдолгом;
  • документация.

Ко второй части относятся неосязаемые понятия, которые также зависят от тимлида:


  • внутренний стандарт качества команды;
  • ответственность за принятие решений;
  • научный подход;
  • нетерпимость к плохим решениям;
  • открытость к экспериментам;
  • ориентация на результат.

Agile-процессы


Почему я пишу Agile? Почему не рассматриваю другие подходы к разработке? Потому что, на мой взгляд, ничего лучше, чем Extreme Programming и принципы Agile Manifesto ещё не придумали. Как еще нам действовать в условиях неопределённости, в которых работает большинство из нас?


Почему налаживание процессов проблема тимлида? Я уверен, что невозможно выпускать стабильный продукт вовремя без налаженных процессов в разработке. Как мы передаём задачи от продукта в разработку? Как проверяем гипотезы? Как уменьшаем риски вкладывания наших усилий не туда? Как релизим? Как даём быструю обратную связь заказчику? Если на эти вопросы не будет чётких ответов, на каждом этапе разработки будут потери времени и усилий на их прояснение. Поэтому, процессы должны сидеть в подкорке мозга каждого члена команды, включая бизнес, дизайн, разработку. И работа тимлида как раз состоит в том, чтобы эти процессы наладить и закрепить. Для этого хорошо подойдёт cookbook свод правил, который стоит обсудить со всеми членами команды и выложить на Confluence/вики/базу знаний команды, показывать новым членам команды при введении в работу, и постоянно совершенствовать его.


SLA


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



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


  • мониторинг сервисов;
  • архитектурную схему;
  • настроенный доступ к критическим системам;
  • налаженные отношения со смежниками.

Мониторинг сервисов


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


Архитектурная схема


Когда я говорю архитектурная схема, я не имею в виду чертёж размером со стену, распечатанный на листах А1 (доводилось видеть и такое). Я, скорее, подразумеваю, что тимлид должен знать все компоненты (микросервисы) в своём владении, бизнес-логику, по которой эти компоненты обмениваются данными, типовые сценарии использования сервиса. Также тимлиду нужно знать путь запроса до приложения со всеми балансировщиками, API-гейтвеями, waf-ами, IPS-ками, ингрессами и прочими проксями это позволит быстро диагностировать проблему и найти ответственных.


Настроенный доступ


Даже при хорошо налаженной схеме дежурства может случиться так, что дежурный недоступен (сел телефон, отключили интернет, крепко спит и т.д.). И в таком случае всё равно реагировать придётся тимлиду. Поэтому важно иметь настроенный доступ во все критические системы, которые могут пригодиться при диагностировании и решении проблемы. Для меня это реплики баз данных, поды Kubernetes/kubectl, ELK, CI/CD, UI RabbitMQ, и конечно VPN, чтобы добраться до всего этого.


Отношения со смежниками


Не секрет, что в современном мире команда разработки не делает продукт в вакууме: всегда, как минимум, есть команда DevOps/эксплуатации, подрядчики с дата-центрами, служба безопасности со своими прокси, DBA с базами, провайдеры связи, DNS, CDN и бесконечное число внешних интеграций. При сбое любого из этих узлов может возникнуть ощущение, что ваш продукт не работает. В этом случае координировать усилия по устранению проблемы придётся тимлиду. Очень важно при этом быть на короткой ноге со смежными командами/подрядчиками: как минимум, нужно иметь все контакты (почтового адреса недостаточно, нужен номер телефона или аккаунт мессенджера). Но лучше, когда у вас со смежниками есть общий чат, в котором в любое время можно организовать взаимодействие. Помогает также заранее провести учения по имитации недоступности систем (мы писали об этом тут), итогом которых станет протокол реагирования на инциденты.


Постоянное улучшение качества


Не секрет, что в погоне за time-to-market мы часто принимаем быстрые решения и встраиваем костыли в наш код (конечно же, с намерением вернуться и всё отрефакторить, когда будет время!).



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


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


Заключение


В этой статье мы рассмотрели, каким должен быть технический уровень тимлида (должен быть опыт разработки). Также, я рассказал, как тимлид может организовать работу с инженерной культурой, процессами, SLA и качеством. В следующей части мы рассмотрим, пожалуй, самую противоречивую часть работы тимлида работу с бизнесом, так что, как всегда, stay tuned!

Подробнее..

Как нанять QA вредные советы

13.04.2021 14:10:30 | Автор: admin

Привет, хабровчане. Подготовили для вас занимательную статью авторства Анастасии Шариковой.

Также приглашаем будущих студентов курса "QA Lead" и всех желающих посетить открытый демо-урок Оценка эффективности тестовой стратегии с помощью тестового покрытия.

На этом вебинаре рассмотрим:

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


Всем привет! Меня зовут Анастасия Шарикова, я Technical Project Lead в Bookmate и веду телеграм канал Yet another QA.

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

  • Никто не откликается на вакансию

  • Отклики есть, но почему-то не от тех, кого хотелось бы

  • Никто не может пройти собеседование с HR/Техническое/Любое другое

  • Те, кто получают оффер, его не принимают и не говорят причины

  • На рынке мало экспертов по нужному направлению

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

Что же делать? Конечно, вариантов много, как и статей, где дается миллион советов о том, как нужно делать правильно, например, такие:

  • Будьте лучшими в своей сфере!

  • Расширяйте сетку поиска!

  • Напишите крутое описание вакансии!

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

Подготовка к найму

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

  • Составление профиля должности лишняя трата времени.

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

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

Вакансия

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

  • Конечно же, мы понимаем, что QA без высшего технического профильного образования нонсенс. А как вы себе представляете прохождение ручных регрессов для приложения со списком задач без магистратуры? Так что обязательно пропишите это в требованиях. И не забудьте упомянуть, что выпускники курсов могут вам не писать пусть кто их учил, тот их и нанимает.

  • Название вакансии дело требующее серьезного подхода, да и путаницы не хотелось бы так что будьте проще, так и пишите Тестер или Q&A профессионалы сразу поймут, о чем речь.

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

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

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

  • В наше время все больше становится актуальной тема T-shape развития, и для сферы QA это тоже актуально. Так что Senior+ специалисты особенно ценят вакансии, где нужно проводить ручное тестирование, и автоматизированное, и заниматься DevOps циклом, но большее время, конечно, отдавать найму, обучению, менеджменту и консалтингу.

  • Ищите специалистов с как можно бОльшим опытом, и желательно, конечно, мужчин около 25-30 лет. Это лучший выбор, и лучше написать об этом сразу в вакансии, чтобы все поняли серьезность ваших намерений.

Собеседования

  • Основа основ, которую стоит проговорить собеседование, даже первое с HR обязательно должно быть очным. Иначе как вы покажете свой прекрасный офис?

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

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

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

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

Организационные процессы

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

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

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

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

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

Подведем итоги

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


Узнать подробнее о курсе "QA Lead"

Подробнее..

Перевод Один год удалённой работы в Figma

13.04.2021 16:13:10 | Автор: admin
image

Оптимизация удалённой работы


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

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

image

Использованный в эксперименте подборщик шаблонов

Наши открытия


Мы выяснили, что пользователи, получившие подборщик шаблонов, имели показатель сотрудничества на 5% больше. Он измеряется как процент пользователей, вносящих правки или комментарии в общий файл. Кроме того, мы заметили, что при помощи подборщика шаблонов пользователи обнаруживали новые функции на 10% больше пользователей обнаружило пресеты кадров, а на 90% больше пользователей использовало в своём процессе творчества файлы Figma Community. Это относилось и к дизайнерам, и к их коллегам, не занимающимся дизайном в число наиболее популярных файлов вошли и специализированные дизайнерские шаблоны (для организации удалённых дизайнерских спринтов), и более общие, например, шаблоны whiteboarding и тим-билдинга.

Даже несмотря на то, что эксперимент проводился с частью нашей пользовательской базы, он не остался незамеченным. Мы получили положительные отзывы в социальных сетях и просьбы о добавлении в подборщик шаблонов документов для других сценариев использования. Рабочие коллективы не просто использовали этот контент, но и благодарили за него. Основная задача Figma Community объединять пользователей, чтобы они могли делиться, учиться и общаться. Это стало идеальным примером того, как мы можем находить способы сотрудничества в мире, где так важна стала удалёнка, полагаясь на работу друг друга.

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

Карта сотрудничества


Отметив положительную реакцию сообщества, мы решили оценить изменения количественно и сопоставить шаблоны с компаниями и регионами, особенно учитывая тот факт, что больше 80% пользователей Figma находится за пределами США. Мир движется в сторону удалённой работы, а мы наблюдаем рост сотрудничества между странами и часовыми поясами. На изображении ниже показаны приглашения и обмены файлами между пользователями в разных странах. Каждая связь обозначает обмен, а каждая страна раскрашена в соответствии с объёмом международного сотрудничества чем темнее страна, тем больше совместной работы.

image

Подробнее о том, что мы выяснили:

Между регионами


В 2020 году Европа была регионом с самым активным ростом международного сотрудничества: в феврале 2021 года количество обменов файлами удвоилось по сравнению с тем же месяцем прошлого года. На глобальном уровне количество файлов, над которыми работают совместно в разных часовых поясах в феврале 2021 года, по сравнению с тем же месяцем прошлого, выросло в 3,5 раза (а для всех файлов в целом рост составил 2,6 раза).

Между дизайнерами и их коллегами


В рамках команд мы наблюдаем тенденцию к тому, что всё больше недизайнеров присоединяется к дизайнерским рабочим пространствам своих коллективов и становятся частью процесса дизайна. В профессиональных коллективах и организациях соотношение дизайнеров и недизайнеров выросло с февраля 2020 года по февраль 2021 года, и на каждого дизайнера в коллективе стало приходиться на 25% больше недизайнеров. С ростом необходимости асинхронных коммуникаций дизайнеры делятся своими файлами в режиме только просмотр с коллегами, чтобы получать обратную связь в реальном времени. Эта тенденция отражается и в росте количества файлов, к которым дизайнеры открывают доступ для своих коллег-недизайнеров (+140%), и в увеличении отношения редактирующий/просматривающий (+12%), произошедших за последний год.

В рамках дизайнерского процесса


Также мы заметили, что большее количество коллективов начало сотрудничать в Figma на более ранних этапах жизненного цикла файлов. В течение 90 дней мы замеряли метрику время до начала сотрудничества измеряемую как количество дней, прошедшее между датой создания файла и первым случаем открытия файла другим сотрудником (не тем, кто создал файл). Среднее время до начала сотрудничества упало на 11% с периода перед началом пандемии COVID до второго квартала года (когда большинство компаний начало работать удалённо), и оставалось стабильным до конца 2020 года.

image

Перенос офлайн-процессов в онлайн


Изучая полученные данные (в дополнение к своему опыту удалённой работы в Figma), мы обратили внимание, что дизайнеры всё активнее делятся файлами со своими коллегами из смежных отраслей, и что это сотрудничество более гибко перетекло в структуры организаций и коллективов. Мы связались с представителями Atlassian и Dropbox, чтобы ознакомиться с их наблюдениями и сопоставить статистику сотрудничества до и после COVID.

Сотрудничество между людьми разных профессий в Atlassian


В начале марта 2020 года Atlassian активно начал использовать Figma сразу после того, как закрыл свои офисы из-за пандемии. Дизайнер Джейк Миллер сказал нам, что переход к работе над файлом в Figma сильно напомнил ему ощущения от работы в офисе с коллегами. Наблюдение за тем, как движутся курсоры, вселяет в тебя ощущение сотрудничества, а не просто сдачи готовой работы по частям, говорит Джейк. Процесс дизайна становится социализированным. И такой уровень сотрудничества выходит за рамки команды дизайнеров, он междисциплинарен. Благодаря использованию файлов Figma в Confluence, каждый становится частью процесса дизайна, рассказывает Джейк. Никто не остаётся исключённым из цикла.

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

image

Граф сотрудничества команды Atlassian в Figma до и после появления COVID

Асинхронность в первую очередь в Dropbox


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

Хотя сотрудники, естественно, стремились решать рабочие вопросы через видеозвонки, это приводило к усталости от Zoom, перегруженности коммуникациями, постоянным контактам и нехватке времени для фокусировки на стратегической и творческой работе, рассказывает вице-президент Dropbox по дизайну Алистер Симпсон.

image

Граф сотрудничества команды Dropbox в Figma до и после появления COVID

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

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

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

Айтишная субстанция

14.04.2021 08:08:47 | Автор: admin

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

Не бойся ошибаться, но работай над ошибками.

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

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

Однажды разработчик написал скрипт, выполняющий нехитрую сортировку файлов по подкаталогам, исходя из имени файла. Разработчик был свеж умом только что вышел из отпуска, за который успел отдохнуть душой и телом. Разработчик был опытен, он не одну сотню раз решал схожие задачи. Разработчик был компетентен, и знал, что не застрахован от ошибки, поэтому проверил скрипт на тестовом окружении, на котором всё отработало, как ожидалось. И даже этого ему было недостаточно, поскольку разработчик справедливо считал любые операции с незарезервированными данными критичными. Поэтому он попросил своего коллегу тоже очень хорошего разработчика сделать ревью этого небольшого и достаточно простого скрипта. Коллега вернулся с одобрением, и разработчик, успокоившись, запустил скрипт на боевом сервере. Всё сработало, на первый взгляд, корректно. А потом начались проблемы. Как обнаружилось при внимательнейшей вычитке, в одном месте скрипта автодополнение поставило $filename вместо $filepath, и любые коллизии в именах файлов приводили к их перезаписи. Разработчик проглядел опечатку, тестовый прогон не учитывал возможность коллизий, а ревьювер не очень хорошо посмотрел код, поскольку не считал себя умнее коллеги.

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

Докапывайся до причин.

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

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

Технические подробности примера выше таковы: в приложении была удобная функциональность сброса к дефолту, написанная когда-то на старте проекта уже ушедшим разработчиком. Другой разработчик нашёл эту возможность, и добавил себе в конфиг её вызов раз в день ему было удобно каждое утро начинать с чистого листа. Ближе к релизу он случайно закоммитил этот конфиг в мастер-ветку; техлид был не на своём месте, и не очень хорошо понимал VCS, считая, что конфиги можно хранить в репозитории. Из-за кранчей и общей усталости изменение прошло мимо ревью, и выкатилось на прод.
Это, конечно, всё равно бы заметили, если б не очень хорошо настроенное кеширование данных в Redis. С ним приложение почти ничего не тащило из БД; запись-то шла, и хотя каждое утро таблички чистились, данные оставались в промежуточном кеше

Ну а дальше понятно: то ли сработал триггер принудительного обновления кеша, то ли Redis перезапустили без восстановления состояния не суть важно. Ежедневные дампы БД всё-таки были но пользы от них уже не было.

Не лезь в IT за деньгами (оно тебя сожрёт).

Ок, программирование одна из немногих профессий, позволяющая чувствовать себя белым человеком. Важная сноска: белым человеком в этой стране, где какие-нибудь полторы тысячи ежемесячных долларов возносят вас в верхний квартиль финансового благополучия. Каждый раз, когда кто-то заводит речь о том, что программисты много зарабатывают, я ору: это не они много зарабатывают, это все остальные получают очень мало!
Но даже это не будут лёгкие деньги. Образ хипстера-смузихлёба, за 300 килодолларов в секунду ненапряжно кодящего очередной стартап на новеньком макбуке фальшивая витрина профессии. В 100% случаев поначалу и в 90% случаев потом ваша работа будет похожа на работу золотаря, только лезть в вонючую яму придётся не руками, а мозгами. Причём частенько, пока вы разгребаете эту яму, сверху будет литься непрерывный поток новых нечистот. И самая мякотка в том, что пролетарий после смены на заводе переодевается из спецовки в треники, кладёт инструмент на полку и болт на работу. Он свободен. А айтишник всегда таскает с собой, если не ноутбук, то голову со всеми этими знаниями и абстракциями, и даже во сне его попускает не всегда.
Это, безусловно, к любой думательной работе относится, но IT наиболее очевидный и хайповый пример.

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

Люби критику.

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

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

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

Не работай в изменённом состоянии сознания.

Как-то, после бессонной ночи, опытный и уверенный в себе разработчик полез на удалённый сервер. Он прекрасно понимал, что писать код сейчас ему сложно это же думать надо! а вот поправить застарелый косяк с некорректными правами доступа на каталоги приложения он может не думая. Задачка, до которой просто не доходили руки, из тех, что выполняются с закрытыми глазами. Можно админов попросить, но это объяснять дольше, чем самому сделать.

Запустив chown под рутом, разработчик увидел неожиданно большой вывод в терминале, и тут же нажал ctrl+c, отменяя выполнение. Но было уже поздно: он опечатался в пути исполнения, вместо каталога приложения задав команде путь от корня. Это практически порушило систему; чтобы всё продолжило хоть как-то работать, пришлось тут же выдать всем объектам 777, и потом уже муторно восстанавливать руками и скриптами.

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

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

Дороже своего времени только время коллег.

Обычный диалог в чате плохой команды:

@username, мне нужно узнать, как сделать X, это твоя тема.
[Через пять минут]
Ау, @username?!
[проходит несколько часов, перемежаемых кидаемыми в чат смешнявками из тематических каналов]
Хай! Ещё надо?
[Нет, я час ждал ответа, не дождался, потратил два часа на самостоятельное разбирательство, хотя ты мог дать мне нужные данные за пять минут, потерял контекст выполняемых задач, и, в общем, профукал день. И это не в первый раз так. Когда ты обратишься ко мне, я тоже не буду торопиться!]
Уже нет, спасибо...

Команда проваливает сроки, получает втык от спонсора, проект закрывается, стартап банкротится, Земля налетает на небесную ось.

Как должен выглядеть диалог в хорошей команде:

@username, мне нужно узнать, как сделать X, это твоя тема.
Ок, смотри туда-то, там краткая дока для себя. Если нужны будут подробности у меня окошко через два часа, можем созвон.
Отлично, спасибо!

Проект выходит в срок, набирает аудиторию, Элон Маск пишет о нём в твиттере, стартап покупает Цукербергман за миллиард долларов, разработчики покупают себе золотые макбуки и начинают писать на них новый стартап.

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

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

Будь учёным.

К сожалению, обучение на айтишника обычно сводится к вот этому:

Баянистый баян из страны баянов

ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ ПОСЛЕДНИЕ 9 КЛАССОВ. ВОТ БЕЙСИК, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ШКОЛЕ, ВОТ ПАСКАЛЬ, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ НА ПЕРВОМ КУРСЕ, ВОТ АСМ, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ ЧЕМУ ВАС УЧИЛИ, ВОТ ДИПЛОМ ПО СИШАРПУ, РЕШАЙТЕ.
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ВУЗЕ, ВОТ ПОХАПЕ, ЗДЕЛАЙТИ НАМ САЙТ ПОЖАЛСТА

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

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

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

Stay calm.

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

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

Спорт необходим.

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

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

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

Комментируй это.

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

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

Не треплись много, треплись мало.

Ежедневное дейли, какая-то летучка, или встреча. Полтора-два десятка человек сидят на пуфиках в опенспейсе, за столом в переговорке или же в Zoom онлайн. И пока один рассказывает скажем, докладывает продакту, чем занимался последний день, остальные тупо тратят своё время.

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

Ну я делал фичу X, там надо было вот это так, но я решил сделать это так, и

...Далее звучат минут всяких косвенных вещей, и заканчивается всё через полчаса подробностями о цвете шерсти собаки, встреченной докладчиком на улице. Если вообще заканчивается.

И все сидят, слушают, не прерывают потому что невежливо. И летучка растягивается на два часа; особенно это круто, если случается в середине рабочего дня, который, таким образом, оказывается потерян вернуться в контекст, из которого тебя вырвали, не так-то просто. Или докладчик начинает на общей встрече разбирать вопрос, который только его касается. Какую-нибудь багу, с которой он может и должен подойти к более опытному коллеге отдельно. Да какого?!..
Это не дело. Для болтовни есть менеджеры, вот пусть они между собой собираются и меряются, у кого софт-скиллы длинней. А время господ разработчиков ценнее и важнее, берегите его.

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

Делай бекапы!

Точно сделал? А если подумать? Автоматические? Инкрементные? На другую физическую машину? А лучше, конечно, на две. А восстановление проверил?

Вот казалось бы, сколько лет твердят: резервируй и перерезервируй но сколько твердят, столько я и натыкаюсь на игнорирование этого правила. Последний раз совсем недавно: бекапы боевой БД то ли не делались, то ли делались на другой раздел той же виртуалки; админский скрипт, удаляющий бесхозные инстансы чпокнул сервер (почему так получилось отдельный разговор). Хоть какие-то данные пришлось выковыривать с dev-окружения, естественно, с потерями и искажениями, не говоря уж о простое сервиса. А ситуацию мог спасти трёхстрочный скрипт, раз в сутки архивирующий дамп, и отправляющий его да хоть по почте, если уж совсем больше некуда.

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

Знай свой инструмент.

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

Собственно, помойка в гите (сто тысяч устаревших серверных веток, мусорные commit message, не относящиеся к делу файлы) это погань, от которой лид команды должен отучивать разработчиков. А за форс пуши уже и наказывать: как правило, форс пуш применяется неопытным разработчиком, как универсальное решение какой-то проблемы, с которой нормально справиться он не смог. Не порешал конфликты при мерже, например, испугался и перезатёр файлик локальным бекапом (он-то по старинке версионируется каталогами!). Беда тут в том, что с гитом работает вся команда, и один косяк может создать проблемы всем сразу.
Хуже ситуации с одним разработчиком, не умеющим в git, только когда в него не умеют все. И всем плевать. И конфиги хранятся в гите, и деплой делается ручками, и тысяча веток на сервере, и хардпуши сразу в мастер, и прочее, и прочее. Видел и вижу такое, к большому сожалению, очень часто.

Впрочем, часто встречаю некомпетентность и в других моментах, и примеров могу привести превеликое множество. Они могут показаться настолько тупыми, что вы решите, будто я их придумал; ах, если бы! Вот, пока я писал эту статью, командный разработчик пожаловался, что ему трудно отлаживать JS-скрипт в браузере через alert();.

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

Подробнее..

Как я перестал превращать собес в экзамен оцениваем хард- и софт-скиллы за одно собеседование

19.04.2021 06:22:01 | Автор: admin

На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"?

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

Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни.

Добро пожаловать под кат.

  1. Про типовой технический собес

  2. А какие есть скрытые резервы в техническом собесе?

  3. А вдруг можно ещё лучше?

  4. Модель STAR(AR)

  5. Что все это дает нам на практике?

Про типовой технический собес

Давайте начнем с того, для чего вообще нужно техническое собеседование.

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

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

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

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

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

Типичное собеседование в компанию "Х"Типичное собеседование в компанию "Х"

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

  • в меру весел,

  • морально неустойчив,

  • есть задел на лидерские качества,

  • при должном стимулировании обучаем,

  • зубы целые,

  • взгляд загадочен.

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

Думаю, основную идею вы уловили собеседование в виде экзамена не помогает ни компании, ни кандидату.

А какие есть скрытые резервы в техническом собесе?

Допустим, вы ищете инженера с опытом администрирования Linux, и вам будет достаточно следующих умений:

  • работать в консоли (команды навигации, работа с файлами);

  • уметь обращаться с логами;

  • менять настройки стандартных системных сервисов.

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

  1. Про стандартные консольные команды навигации и работы с файлами (cd, mkdir, cp, mv . плюс дежурная шутка про то, как выйти из vi);

  2. Про то, где находятся логи разных сервисов (syslog, error_log/error.log .);

  3. Про то, где находятся файлы конфигураций разных сервисов (httpd.conf/apache2.conf, php.ini, my.cnf и т.д.).

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

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

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

В ответ есть вероятность услышать что-то вроде:

Включу нужные опции в секции Error handling and logging файла конфига php.ini, там же посмотрю опцию error_log, чтобы найти, где хранятся логи.

В логе найду ошибку о том, что The uploaded file exceeds the upload_max_filesize directive in php.ini, после чего поправлю соответствующую опцию в php.ini, задав нужный разумный предел.

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

Казалось бы, это то, что надо! Но

А вдруг можно ещё лучше?

Давайте зададим кандидату вопрос в следующем ключе:

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

Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?

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

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

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

Решение: Путем курения логов наш кандидат выяснил, что виноват не формат файла, а его размер. Поразбирался в настройках php.ini и пришел к решению установить директивы upload_max_filesize = 20M и post_max_size = 20M. Это решило проблему. Поправленные настройки кандидат добавил в инструкции по деплою и настройке продакшн сервера.

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

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

Это ли не чудо?

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

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

Хотите ли вы, чтобы человек с таким набором знаний, умений и качеств работал с вами в команде?

А теперь давайте разберем, как мы это добились.

Модель STAR(AR)

Напомню, вопрос кандидату звучал как:

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

Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?

Для вопроса мы использовали модель STAR(AR). Эта модель состоит из четырех (либо пяти) важных составляющих:

  • Situation (ситуация).

  • Task (задача).

  • Actions (действия).

  • Results (результаты).

  • Alternative Results (альтернативные результаты).

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

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

Дополнительный приятный бонус скрывается в пункте Alternative Results. Вопрос как бы вы поступили в такой же ситуации сейчас? может показать, чему кандидат научился с тех пор, как рассказанная ситуация случилась в его жизни. А это уже намекнет вам на способность переосмысливать свой опыт, учиться и делать выводы, даже если изначальное решение было неоптимальным, а то и вовсе неправильным.

Давайте представим, как наш кандидат мог бы ответить на этот вопрос, пусть это будет:

Сейчас я бы установил директиву post_max_size = 60M, т.к. сама форма загрузки позволяла загружать до 3 файлов одновременно.

Готово, вы восхитительны! Похоже, что наш кандидат нам подходит.

Что все это дает нам на практике?

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

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

Бонусный уровень

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

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

А как вы оцениваете софт скиллы? Какие техники или методы используете для этого?

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru