🗣 🦠 👥 Лжеэкономия на удаленке



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

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

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

Да очень просто. Качественный фрилансер — это профи, который все умеет и не нуждается в няньке. Это онлайн-человек. Он прекрасно себя чувствует на внутреннем или на русскоязычном рынке, а если не поленился подтянуть английский, то и на международном. С чего ему стоить дешево? Может, вы выиграете процентов пятнадцать на квартирно-транспортных расходах. Или не выиграете, если его специализация востребована. На Senior Java dev-e не сэкономите точно. )

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

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


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

promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

‼️ Технарям о текстах



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

Дам несколько дельных советов. Годятся и для технических документов, и для писем клиентам или коллегам.

1. Не пиши текст с первого раздела. Начинай с самой важной мысли, с самой важной части. Даже если это последние пять строк документа. Введение напишешь потом, когда основная мысль будет отточена и завершена. Если начинать писать текст так, как его будут читать, то потратишь кучу времени на раздел «Общие положения» и ему подобные. А потом все равно придется переписывать.

2. Запомни: ты не стилист уровня Чехова или Довлатова. Ты не сможешь написать сразу так, чтобы читатель подпрыгивал от восхищения. Ни-ко-гда. Начни писать так, как ты думаешь: корявенько, не подбирая слов, путаясь в предложениях и мыслях. Если легче с матом – матерись. Вывали на бумагу всю страшненькую кучу своих мыслей. И только потом начинай искать верные формулировки и подходящие слова, разгребай ее, делай из кучи конфетку. Сразу написать хорошо не выйдет.

3. Запомни: чем короче, тем лучше. Для текста это точно справедливо. )) Не пиши длинных предложений. Если получилось длинное, разбей на несколько коротких.

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

5. Проверь документ перед отправкой. В нем не должно быть ошибок, опечаток, несогласованных частей предложения, лишних скобок и кавычек. Не уверен в своей грамотности – пользуйся автоматическими средствами проверки орфографии. Если в документе есть ошибки, то и к автору документа, и к его компании, и к его продукту отношение как к … гм… ну, ты понял. Я уж молчу про ошибки в интерфейсе продукта.

Тексты – это важно.

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

🤷♀ Не забывать о ловушке аналогий



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

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

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

Бизнес-идеи поясняют отраслевыми аналогиями. «Это как Uber для животных». «Это как ворд, но онлайн». «Это как варкрафт, только в комосе».

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

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

Аккуратнее с аналогиями.


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

📝 Эскалационная азбука



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

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

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

Чтобы эскалация работала, надо следовать нескольким простым правилам. Простым, но обязательным.

1. Эскалация — это инструмент управления. Прежде чем им пользоваться, надо убедиться, что на твоем уровне ты сделал все, что мог. И все, что должен был.

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

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

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

5. Эскалация — это инструмент управления. Работает он с фактами, а не с домыслами. Желательно — с письменными фактами. Тогда вам тоже станет понятно: есть документированная проблема или чьи-то действия всего лишь не соответствуют вашим ожиданиям. Или, может, вам кто-то персонально не нравится? Это не повод для эскалации.

6. Эскалация — это инструмент управления. Ее не надо бояться. Менеджер не выглядит слабым, если эскалирует проблему. Он выглядит слабым, когда проблема неожиданно для всех всплывает, а о ней никто не знал.

7. Эскалация — это инструмент управления. Им надо уметь пользоваться. Чтобы уметь — надо учиться. И чтобы во время обучения люди не пострадали.

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

📚🧑🏿💻📚 О дистанционном обучении новичков



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

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

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

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

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

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

Ситхи тоже не просто так везде по два бродили — понимали, что без наставника никак. )

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

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


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

🤲 Право на отказ



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

Попросить и дать право на отказ - существенно увеличить шансы на выполнение задачи.

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

🔤 Протоколы, задачи и необоснованные ожидания



Вот представьте: менеджер собрал свою команду и представителей заказчика на большую встречу. Обсудили горячие вопросы, определили список важных дел. Менеджер оформил протокол встречи, красиво отформатировал. Поставил сроки, ответственных. Разослал протокол всем участникам. Первым пунктом в протоколе стоит что-нибудь вроде: «Передать обновленную систему для создания отчетов. Ответственный — инженер Герман Поклюйкин. Срок — 3 марта». Герман был на встрече и кивнул, когда это обсуждали.
Менеджер, который протокол писал, думает, что дело сделано, систему передадут 3 марта.

Но приходит уже 4 марта, а ничего не сделано. Уж полночь пробило, а Германа все нет. И 5 марта тоже ничего не передали. Но ведь в протоколе, который Герману тоже выслали, все написано! Как же так?

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

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

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

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

Неправильная цепочка: написал ответственного в протоколе встречи → ожидаю, что он читает протокол и все сделает → расстроился, что ничего не сделано в срок или сделано не то → получил люлей от клиента → наказал инженера.

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

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

🤦🏽 Perception is always reality



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

Я думаю, такие проблемы в интерфейсе надо решать административными методами. )

По тому, что у вас в интефейсе написано, ваш продукт и оценивают. Perception is reality.


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

🍿🥤 Шесть фильмов и один сериал для менеджеров



1. «Войны Пентагона» (The Pentagon Wars, 1998) — про суть проектной работы и взаимоотношения заказчиков и исполнителей. 

2. «Лок» (Locke, 2013) — про работу менеджера без аджайла, макбука и смузи.

3. «Американцы» (Glengarry Glen Ross, 1992) — про переговоры и умение слушать.     

4. «Человек, который изменил все» (Moneyball, 2011) — про то, как отсекать неважное и фокусироваться на важном.  

5. «Отель «Руанда» (Hotel Rwanda, 2004) — про работу управленца в действительно стрессовой ситуации.

6. «Операция «Колибри» (The Hummingbird Project, 2018) — про самоотверженность менеджера и отличия успешного проекта от успешного продукта.

7. «Бумажный дом» (La casa de papel, 2017) — про то, что неуспех проекта и продукта зависит не от процессов, техники или рынка, а только от неподходящих людей в команде.

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


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

🔭 Zoom для общения команд: пара фишек



Несколько советов по рабочему общению в Zoom.

1. Попросите всех (и клиентов тоже) регистрироваться под нормальными именами и фамилиями. Вам не придется во время виртуального стендапа вспоминать или угадывать, кто такие "fuckinator31", "aabb" или "Весна-красна".

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

3. Используйте виртуальный фон (Virtual Background). Не все успели сделать дизайнерский евроремонт под ключ. А фон решает эту проблему сразу. А еще он настраивает на рабочий лад, не позволяя уплыть в разглядывание особенностей быта коллег.
Совет 1: подберите фотку фона так, чтобы реальное освещение ей соответствовало. Если на фото залитая солнцем комната, лучше в реальности тоже сесть возле солнечного окошка. Так вы лучше впишетесь в фон и все будет выглядеть естественнее.
Совет 2: лучше всего сделать фоном не пляж с набегающей на песочек волной и не космический пейзаж, а фотку привычного вашего офиса. Если нет офиса - что-то привычное без избытка деталей. У меня один сотрудник сделал фоном фото трехэтажной хрущевки в Челябинске. Выглядит нормально.)

4. В настройках отключите видео и звук при входе в конференцию. Особенно если вы ее организатор. А то вдруг вы забыли брюки надеть, а не уселись еще за стол. Конфуз.)

5. Не жуйте во время конфы. Это и с отключенным видео ужасно, а с включенным - вообще кошмар. И отодвиньте бокал кьянти от камеры.)


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